home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group96a.txt
/
000139_icon-group-sender _Tue Jun 18 13:09:09 1996.msg
< prev
next >
Wrap
Internet Message Format
|
1996-09-05
|
2KB
Received: by cheltenham.cs.arizona.edu; Tue, 18 Jun 1996 13:13:57 MST
X-Sender: nevin@192.12.69.186
Message-Id: <v02140b00adecbab40584@[150.135.1.79]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 18 Jun 1996 13:09:09 -0700
To: "Icon Group" <icon-group@cs.arizona.edu>
From: nevin@cs.arizona.edu (Nevin ":-]" Liber)
Subject: Re: Locking files
Errors-To: icon-group-errors@cs.arizona.edu
Status: O
At 5:11 AM 6/18/96, Hamish Lawson wrote:
> Jerzy Karczmarczuk wrote:
> > there is a cheap way of locking something
> > globally used for ages: the *creation* of a special "lock" file
> > just before entering the critical section (if it is absent,
> > otherwise sleep/wait), and the destruction after.
> Is there not a small risk that in the time between some process finding
> that the lock file doesn't exist and creating this file, another process
> might also find that the lock file doesn't exist, thereby breaking the
> exclusivity mechanism.
Under Unix (this stuff is OS dependent, making it difficult to abstract
away in a high level language), opening a file is an atomic operation. If
you are programming in C, you can set the flags during open to create a
file if and only if it does not already exist, making it a very expensive
but fully functional TestAndSet instruction (basic primitive needed to
implement semaphores). However, there does not appear to be a way to get
at this mechanism from Icon itself.
--
Nevin ":-)" Liber nevin@CS.Arizona.EDU (520) 293-2799
http://www.cs.arizona.edu/people/nevin/